1. Technical Field
The present invention relates to a long-term signature server, long-term signature terminal, and long-term signature verification server, and for example, relates to forming of long-term signature data.
2. Background Art
In order to authenticate electronic data, electronic signing is performed by encrypting electronic data with a private key and an electronic signature, which is verified by the electronic data being decrypted using a public key which corresponds to the private key, is widely used.
Due to the electronic data being decrypted using the public key, it is possible to recognize that the electronic data has been encrypted using the private key which corresponds to the public key, and it is possible to confirm that the electronic data is by the signatory since it is the signatory that has the private key. By way of comparison, the private key functions as a seal and the public key functions as a seal certificate.
The public key is distributed using a public key certificate which is issued by a certifying authority and those who receive the distribution are able to confirm the authenticity of the public key using the certificate.
However, in order to deal with the compromising and the nature of the encryption algorithm which is used for the signature and the like in the electronic signature, an expiry date is set.
In addition, even before the expiry date, there are cases where the all of the certificates are revoked from the root certificate due to being revoked by circumstances relating to the signatory, loss of the private key, or the like.
Therefore, in order to cope with this problem, as shown in Patent Literature 1, an electronic signature format (below, long-term signature format) is regulated for making the validity of the electronic signature permanent.
This regulation is defined overseas by RFC5126 or ETSI TS 101 733 and is defined in Japan by JIS standard (JIS X 5092/5093).
The long-term signature format is configured from ES, STS, ES-T, verification information, ES-XL, ATS (1st, 2nd, . . . ) as shown in FIG. 1. This content will be described later in an embodiment.
FIG. 11 is a diagram for describing a configuration example of a long-term signature system 100 in the related art.
The long-term signature system 100 is configured from a long-term signature server 101 which is disposed at the client side, a CA repository 103 which exists in an external network 102, a TSA 104, and the like.
First, the long-term signature server 101 receives electronic data which is a signing target (hash value of original data) (step 5), signs the electronic data with the private key and generates ES (step 10), is applied with a signature time stamp by being sent to a TSA 104 (step 15), and outputs an ES-T (step 20).
Next, the long-term signature server 101 receives the ES-T which has been output (step 25), acquires revocation information from a CA repository 103 (step 30), and determines whether the revocation information has been issued after a certain period of time has passed (step 35). This is for acquiring the latest revocation information.
Next, the long-term signature server 101 acquires a certifying pass of a certificate (step 40) and applies verification information using the revocation information and the certifying pass (step 45).
Then, the long-term signature server 101 generates information which is the basis for ATS, electronically signs, and generates ATS by applying the time stamp using the TSA 104 (step 50) and outputs an ES-A (step 55).
It is possible to acquire long-term signature data in the manner described above, however there is a problem in that the long-term signature server 101 is disposed at the user side and it is necessary that operation management be performed at the user side.
In addition, since it is not easy to estimate the usage rate of the long-term signature data and the immediate effect is difficult to sense by the user, there are problems where the initial installation cost does not match the assumed costs of the user and it is difficult to install the long-term signature system.
In relation to this problem, for example, as shown in FIG. 12, it is possible for it to be dealt with by a method where a third party operates the long-term signature server 101 and the user forms long-term signature data by accessing the long-term signature server 101 from a client terminal 106.
However, in this case, it is necessary that the user transmit original data (internal document data and the like) which is a signing target of the long-term signature data to the long-term signature server 101 other than entrusting the private key which is used as the electronic signature to the long-term signature server 101, and there is a problem that it is necessary that confidential information (the private key, the original data) be released to the outside.
In addition, it is necessary that the confidential information be provided to a verification server in the same manner as the verification of the long-term signature data, or that a verification server be provided in-house.